The UML dataset consists of class diagrams, the most important type of diagrams when designing a new application. These diagrams are very diffused because they can describe both conceptual characteristics of an application and specific modeling details which can be directly translated into programming code.

The dataset is saved in XMI format (XML Metadata Interchange). This format is a standard from Object Management Group (OMG) used for the exchange of metadata through XML. It can be potentially used for every kind of artifact whose metamodel can be fit into Meta-Object Facility (MOF) structure. However, the most usual use case is the exchange of UML models.

The dataset consists of metamodels coming from the AtlanMod zoos, a research team in common between INRIA (Institut National de Recherche en Informatique et en Automatique) and LINA (Laboratoire d'Informatique de Nantes Atlantique). It is composed by a total of 301 models expressed in UML 2.1 conforming to the Ecore metamodel from Eclipse Modeling Framework (EMF). These models are actually metamodels (for example the metamodel of HTML 1.0), but since a metamodel is still a model all the hypotheses made in this document are still valid.

In Figure~\ref{fig:uml_dataset_example} you can see an example of UML project model from the dataset discussed above.
\begin{figure}[ht]
  \begin{center}
	\includegraphics[width=0.5\textwidth]{./pictures/uml_dataset_example}
	\caption{An example of UML project model from AtlanMod zoos dataset.}
	\label{fig:uml_dataset_example}
  \end{center}
\end{figure} 
The example in Figure~\ref{fig:uml_dataset_example} shows a project model named ``MSProject'' with two packages. The only significant package is the one with the same name of the project. This package contains three classes connected by two relations.

\lstset{
language=XML,
breaklines=true,                % sets automatic line breaking
breakatwhitespace=false,        % sets if automatic breaks should only happen at whitespace
basicstyle=\footnotesize	% the size of the font
}

The code below shows the XML representation of the model in Figure~\ref{fig:uml_dataset_example}.
\begin{lstlisting}
<...
  <packagedElement xmi:type="uml:Package" xmi:id="_e6BjkeiaEd6gMtZRCjS81g" name="MSProject">
    <packagedElement xmi:type="uml:Association" xmi:id="_e6BjmeiaEd6gMtZRCjS81g" name="A_MSProject_Task" memberEnd="_e6BjmOiaEd6gMtZRCjS81g _e6BjmuiaEd6gMtZRCjS81g">
      <ownedEnd xmi:id="_e6BjmuiaEd6gMtZRCjS81g" name="" type="_e6Bjk-iaEd6gMtZRCjS81g" isUnique="false" association="_e6BjmeiaEd6gMtZRCjS81g">
        <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_e6CKpeiaEd6gMtZRCjS81g" value="1"/>
        <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_e6CKpuiaEd6gMtZRCjS81g" value="1"/>
      </ownedEnd>
    </packagedElement>
    <packagedElement xmi:type="uml:Association" xmi:id="_e6BjnOiaEd6gMtZRCjS81g" name="A_Task_Task" memberEnd="_e6Bjm-iaEd6gMtZRCjS81g _e6CKoOiaEd6gMtZRCjS81g">
      <ownedEnd xmi:id="_e6CKoOiaEd6gMtZRCjS81g" name="" type="_e6BjleiaEd6gMtZRCjS81g" isUnique="false" association="_e6BjnOiaEd6gMtZRCjS81g">
        <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_e6CKqeiaEd6gMtZRCjS81g" value="1"/>
        <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_e6CKquiaEd6gMtZRCjS81g" value="1"/>
      </ownedEnd>
    </packagedElement>
    <packagedElement xmi:type="uml:Class" xmi:id="_e6Bjk-iaEd6gMtZRCjS81g" name="MSProject">
      <ownedAttribute xmi:id="_e6BjmOiaEd6gMtZRCjS81g" name="tasks" type="_e6BjleiaEd6gMtZRCjS81g" isUnique="false" aggregation="composite" association="_e6BjmeiaEd6gMtZRCjS81g">
        <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_e6CKo-iaEd6gMtZRCjS81g" value="*"/>
        <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_e6CKpOiaEd6gMtZRCjS81g" value="1"/>
      </ownedAttribute>
    </packagedElement>
    <packagedElement xmi:type="uml:Class" xmi:id="_e6BjlOiaEd6gMtZRCjS81g" name="NamedElement" isAbstract="true">
      <ownedAttribute xmi:id="_e6BjluiaEd6gMtZRCjS81g" name="name" type="_e6CKoeiaEd6gMtZRCjS81g" isUnique="false"/>
    </packagedElement>
    <packagedElement xmi:type="uml:Class" xmi:id="_e6BjleiaEd6gMtZRCjS81g" name="Task">
      <generalization xmi:id="_e6CKouiaEd6gMtZRCjS81g" general="_e6BjlOiaEd6gMtZRCjS81g"/>
      <ownedAttribute xmi:id="_e6Bjl-iaEd6gMtZRCjS81g" name="UID" type="_e6CKoeiaEd6gMtZRCjS81g" isUnique="false"/>
      <ownedAttribute xmi:id="_e6Bjm-iaEd6gMtZRCjS81g" name="predecessors" type="_e6BjleiaEd6gMtZRCjS81g" isUnique="false" association="_e6BjnOiaEd6gMtZRCjS81g">
        <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_e6CKp-iaEd6gMtZRCjS81g" value="*"/>
        <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_e6CKqOiaEd6gMtZRCjS81g"/>
      </ownedAttribute>
    </packagedElement>
  </packagedElement>
  <packagedElement xmi:type="uml:Package" xmi:id="_e6BjkuiaEd6gMtZRCjS81g" name="PrimitiveTypes">
    <packagedElement xmi:type="uml:PrimitiveType" xmi:id="_e6CKoeiaEd6gMtZRCjS81g" name="String"/>
  </packagedElement>
</uml:Model>
\end{lstlisting}

As you can see in the code above, each class is represented by a \emph{packagedElement} element with \emph{type} attribute \emph{uml:Class}. The \emph{packagedElement} elements that represent classes are saved inside other \emph{packagedElement} whose \emph{type} attribute is set to \emph{uml:Package}. Class attributes are put in \emph{ownedAttribute} elements saved as children of the class they belong to. This dataset contains three kinds of UML relationships: association, composition and generalization. These three relationships are treated as simple attributes and they are saved as children of the class they belong to: generalizations are saved within a specific element \emph{generalization}, associations and compositions are inside \emph{ownedAttribute} elements (compositions has the \emph{aggregation} attribute set to \emph{composite}). The information about the referenced class is saved in the \emph{type} attribute inside the ownedAttribute element. The cardinalities of the relationships that have the direction specified into the model are saved directly as children of the \emph{ownedAttribute} representing the relationship, while the cardinalities in the opposite direction are saved as children of a different \emph{packagedElement} with \emph{type} attribute set to \emph{uml:Association}. For example the classes \emph{MSProject} and \emph{Task} are connected through the association \emph{tasks} (starting from the class \emph{MSProject}  to class \emph{Task}). The association is saved in the class \emph{MSProject} (the starting class). The upper cardinality is ``*'' (many) and lower cardinality is ``1'' (a project can have from one to many tasks to be performed). The cardinalities in the opposite direction are saved at the beginning of the XML code within a different packagedElement. The relationship in the opposite direction references the \emph{association} attribute saved into the packagedElement that represents the class owning the relationship through the \emph{xmi:id} attribute. In the example above, the opposite cardinalities (upper value and lower value) are both ``1'' (a task can belong to only one project).

In Figure~\ref{fig:UML_Dimensioni} you can see an histogram showing the distribution of the number of classes into the UML projects dataset.
\begin{figure}[ht]
  \begin{center}
	\includegraphics[width=0.7\textwidth]{./pictures/UML_Dimensioni}
	\caption{Histogram that shows the distribution of the number of classes into the UML projects dataset.}
	\label{fig:UML_Dimensioni}
  \end{center}
\end{figure} 

\noindent The histogram points out the following information:
\begin{itemize}
	\item 272 diagrams have less then 100 classes,
	\item 22 have a number of classes between 100 and 400,
	\item 7 diagrams have more than 400 classes (the maximum number of classes for a diagram is 700).
\end{itemize}

\noindent The dataset has an important limitation: the average dimension of the projects is quite small, while only a small number of projects is huge. Another drawback is that, as it often happens in UML modeling, classes are organized in packages, but most of the diagrams from this dataset have only 2 packages, with just 46 diagrams having more than that. Moreover, among the diagrams with 2 packages, most of them contain one package which is not significant as it contains only data types classes.

Figure~\ref{fig:uml_dataset_terms_distribution} depicts the frequency distribution of terms of the UML dataset (301 models). We show the distribution up to the first two hundred terms.
\begin{figure}[htbp]
  \begin{center}
	\includegraphics[width=0.5\textwidth]{./pictures/UML_dataset_term_distribution.eps}
	\caption{The frequency distribution of terms of the UML dataset.}
	\label{fig:uml_dataset_terms_distribution}
  \end{center}
\end{figure}

As the figure suggests, the distribution of terms approximates a power-law function and, therefore, it follows the Zipf's law.

For the purpose of the tests of the UML case study, we used 84 models out of the total of 301 models available in the dataset.